From the basics to day-to-day operations WordPress questions, answered

It is software for building and running a website. You install it on a server, then log in from a browser to write posts, change menus and pick a design — without touching HTML each time.

Software like this is called a CMS (content management system). WordPress started as a blogging tool, but today it runs company sites, shops, booking systems and portfolios just as well.

wordpress.org is where you download the software. You install it on your own server and own every file and the database. This is often called “self-hosted”.

wordpress.com is a company that runs that software for you. There is nothing to install, but your plan decides which plugins you may use and how far you can change the code.

Everything on this site is about the self-hosted version, and our support program covers only that.

WordPress itself is free, distributed under the GPL open-source licence. You may use it commercially and modify the code if you want to.

What does cost money is running the site — hosting and a domain are separate, and paid themes or plugins add to that. The Cost & hosting category breaks the numbers down.

Company sites, blogs, magazines, portfolios, booking pages and online shops. What you end up with is decided by the combination of a theme (how it looks) and plugins (what it does).

It is not always the right fit. Real-time collaboration tools or complex internal business systems — where every screen has its own logic — are usually better built from scratch.

A theme is the appearance — fonts, colours, layout, where the menu sits. Only one is active at a time.

A plugin is a capability — contact forms, payments, SEO tools, backups; anything WordPress does not do out of the box. You can run many at once.

Change the theme and the clothes change; switch off a plugin and that capability disappears. Knowing which is which tells you where to look when something breaks.

Day-to-day work — writing posts, building menus, uploading images — needs no code at all. Picking a theme and adjusting colours is mostly done from the admin screen too.

Code tends to become necessary in three situations: a layout your theme does not offer, two plugins conflicting and needing to be traced, and server configuration. The first two are covered in our technotes; the third is exactly what our support program takes off your hands.

More precisely: WordPress is not weak — it is everywhere and its code is public, so attackers never stop looking. That is the flip side of openness, not a defect.

In practice, vulnerabilities are usually patched the day they are disclosed. Incidents happen on sites that went years without applying those patches. The problem is neglect, not the tool.

Update on time, delete plugins you no longer use, keep admin accounts under control, and most of it is closed off. Taking that work off your hands is what we do.

Log in as an administrator and look at the Dashboard: the “At a Glance” panel says “WordPress x.x running”. You can also find it under Tools → Site Health → Info.

If your version is several releases behind, every security patch published in between is missing. To see what is outstanding in one pass, try our free audit plugin.

Builders are faster to start: no server to choose, no updates to keep up with. In exchange, features and design stay inside what the service allows, and moving the site elsewhere is hard.

WordPress gives you ownership and portability. The files and database are yours, so the site follows you to a new server. In exchange, updates and backups are your responsibility.

The deciding questions are how long you plan to run it and how much you expect to change. If the maintenance is the worrying part, that is the part you can hand over.

The admin interface and most major plugins are translated, and Korean typography and search visibility are both manageable through configuration.

A few things do need local attention: registering with Naver differs from Google, Korean payment gateways often do not fit foreign plugins, and Korean-language URL slugs can misbehave depending on server configuration.

We work through these one at a time in the SEO and server & infrastructure technotes.

Two costs are fixed: a domain (yearly) and hosting (monthly). The WordPress software itself is free.

Optional costs sit on top: a paid theme (usually a one-off), paid plugins (often renewed yearly), and labour for anything you do not do yourself.

Prices vary so much by provider and specification that we will not quote them here. What we will say is that the most common mistake is going too cheap on hosting — that one choice quietly decides how much performance and security work is possible later.

Shared hosting puts many sites on one server. It is cheap and easy to start, but you cannot change server configuration, and a busy neighbour affects your speed. cPanel-style control panels usually mean shared hosting.

Server hosting — a VPS, cloud instance or dedicated machine — gives you the server (or your slice of it) with root access, so the web server, PHP and caching can be configured as needed.

That is why our support program only accepts server hosting: on shared hosting the work we promise is simply not possible.

Look at the conditions rather than the brand.

• Root or sudo access — without it, performance and security work is sharply limited
• Can you choose the PHP version? Being pinned to an old PHP means you cannot run current WordPress
• Memory — WordPress uses a lot during image processing; too little and uploads fail
• Backups or snapshots — is there somewhere to return to when something goes wrong?
• Server location — if your visitors are in one country, a nearby region helps response time

You can reach a site by its server address, but running one properly needs a domain — it is memorable, it lets you attach an HTTPS certificate, and it survives a change of server.

It does not have to come from your host. Wherever you buy it, you just point its DNS at your hosting server. Keeping domain and hosting with different providers actually makes it easier to move one without the other later.

No. Plenty of sites run perfectly well on a free theme from the official directory.

A premium theme earns its price mainly when a ready-made layout is already close to what you need — at that point you are buying development time.

One condition comes with it, though: when the licence lapses, updates stop. A theme that no longer receives updates accumulates exposure over time, so count the renewal into the price before you buy.

Do not. These builds — usually called “nulled” — frequently carry a backdoor. Installing one hands control of your site to a stranger.

If cost is the issue, look for a free alternative instead. Most capabilities have a free version in the official directory, and if none exists it is worth asking whether you really need that capability.

Worth adding: even a genuine paid plugin that stops being updated creates the same problem, because patches never arrive after a vulnerability is published.

₩270,000 including VAT by Korean bank transfer, or $200 USD via PayPal. It is a flat price and does not scale with the size of your site.

That covers the upgrade, performance tuning, technical SEO, security hardening and a Docker-based deployment, all in one engagement. What is not included is written out with equal weight on the program page.

If you want ongoing monitoring, InfraGuard passes are separate — ₩120,000 / $80 per month, with a one-month trial included by default for program customers.

Before work starts, in full. After it starts, we settle according to how far it got — the conditions and the procedure are written out case by case on the refund page.

The most common reason for a refund is hosting that turns out not to meet the conditions, so we check that at the request stage rather than letting you discover it after paying.

Two routes.

Your host’s installer — many providers set it up from their control panel in a few clicks. This is the fastest.

Manual install — download the archive from wordpress.org, upload it, create a database, then open the site in a browser and the setup wizard appears. It asks for four things: database name, user, password and host.

Either way, immediately afterwards make sure the administrator username is not “admin” and the password is long — that combination is the first thing automated login attempts try.

Either there is no HTTPS certificate or it is not being applied. Free certificates (Let’s Encrypt) are issued automatically by most hosts these days, so check your control panel first.

If the padlock still does not appear after installing one, it is usually mixed content: the page loads over https but an image or script inside it still points at an http address. Change both address fields under Settings → General to https, and replace the remaining http URLs inside your content as well.

Add /wp-admin/ to your site address — for example example.com/wp-admin/. If you are not logged in you will be sent to the login page at /wp-login.php.

Because that address is identical on every WordPress site, automated login attempts never stop. The defences that actually work are a long password and two-factor authentication — moving the address alone is not enough.

A post is content that accumulates over time. It has a date, is grouped by categories and tags, and appears in reverse-chronological lists — news, blog entries, announcements.

A page is fixed content with no relationship to time: About, Terms, Contact. Pages have no categories but can be nested under one another.

When in doubt ask: “should this pile up in a list?” If yes, it is a post; if no, a page.

Under Settings → Permalinks. Choosing “Post name” gives you /post-title/, which reads better for both people and search engines.

Two things to watch.

• Existing post URLs change. Old links break, so on a live site you must 301-redirect the old addresses to the new ones
• Korean titles produce very long auto-slugs. Each character becomes several bytes once encoded, and a long title can be truncated into a 404. Setting a short Latin slug per post is safer

Under Appearance → Menus. Drag pages, posts, categories or custom links into order; nudge an item to the right to make it a sub-item.

After building it you must assign a display location under “Menu Settings” — if you saved a menu and nothing changed on the site, this is almost always the missing step.

On block themes (where Appearance shows “Editor” instead) you change it through the navigation block in the site editor.

If the upload itself fails, it is usually the server’s upload size limit (upload_max_filesize) or not enough memory. Raise it in your hosting settings, or shrink the file before uploading.

If the site merely feels heavy, the cause is almost always photos uploaded at full original size — camera and phone images are far larger than any screen needs.

Resize to the width you actually display before uploading, and save as WebP where you can. If a large library has already accumulated, clearing it in one pass during performance work is faster — see the performance technotes.

By default WordPress sends mail through the server’s PHP mail(), which carries no authentication — so messages are routinely marked as spam or dropped outright. Nothing is wrong with your code.

The fix is to send over SMTP instead: give WordPress the credentials of a real mailbox (your company mail, or a sending service) so messages go out as that account. An SMTP plugin makes this a settings screen.

Setting SPF and DKIM on the sending domain makes it steadier still.

Under Settings → General → Site Language. The translation files are downloaded and applied as soon as you choose.

Set the timezone on the same screen while you are there. A wrong timezone means scheduled posts do not publish when you intended, and the post list does not make that obvious — it is the usual reason a scheduled post appears to have quietly vanished.

If different users need different languages, each profile can override it individually.

Leave “do I like the design” until last. Four things come first.

• Has it been updated recently? A theme untouched for years is likely to break on the next WordPress release
• What does it drag in? Themes that need a slider, an icon pack and a page builder to look like the demo are that much slower
• Does it support child themes? You need one to keep your changes
• Does it hold up in Korean? Line breaking and letter spacing tuned for Latin text will chop headings in odd places

Edit theme files directly and every change disappears the moment the theme updates. A child theme leaves the original untouched and layers your changes on top, so updates no longer erase your work.

For a line or two of CSS, Additional CSS (Appearance → Customize) is enough. A child theme becomes necessary when you change template files or add functions.

The test is simply: is this a change an update may delete? If not, use a child theme.

Your posts and pages keep their content — it lives in the database. What disappears is the way it was being presented.

What actually breaks:

• Menu locations — reassign them in the new theme
• Widgets — they lose their place if the sidebar names differ
• Theme-specific shortcodes — something like [button] from the old theme is left as literal text inside your posts
• Customizer settings — colours and logos are stored per theme

On a live site, switch on a copy first, check it, then move.

If your theme’s customizer offers font settings, use those; otherwise set font-family in Additional CSS.

Korean web fonts come with two considerations Latin ones do not.

• They are large. With so many glyphs the files are heavy — splitting into subsets so only the needed ranges load makes the first paint much faster
• Default line height is too tight. Most themes assume Latin text at around 1.5, which feels cramped once Korean syllable blocks with final consonants are involved. Around 1.7 reads better for body text

Hosting the font on your own server rather than a third-party CDN is better for both speed and privacy.

You can. Laying out a page without writing code is a real advantage.

It comes at a price: the layout ends up inside the database. Switch the builder off and the page collapses; moving the site or version-controlling it becomes awkward. The extra scripts and styles on the front end cost speed too.

The workable compromise is to fix its scope — use it for body content you edit often, and not for the site’s skeleton: header, footer, repeated templates. That is how we run this site.

The usual cause is one element that cannot shrink: an oversized image, a fixed-width table, or an unbreakable string such as a very long URL. That single item pushes the viewport wider and the whole page gains a horizontal scrollbar.

Open your browser’s responsive mode and narrow the width until you can see which element sticks out. Usually max-width: 100% on images and a horizontal scroll container around tables settles it.

⚠ Do not conclude “no horizontal scrollbar, so it is fine” — if an ancestor is clipping the overflow, content is simply cut off with no scrollbar to reveal it.

A classic theme renders through PHP template files, with colours and logos changed in the Customizer. It is the older approach and still widely used.

A block theme builds even the header and footer from blocks, all edited in the Site Editor. If your Appearance menu shows “Editor”, you are on a block theme.

Neither is simply better — the one you are fluent in is. Do note that the block-theme ecosystem is still thinner, and some plugins you need may assume the classic model, so check compatibility before committing.

Do not work on the live site. The order is:

1. Make a copy — files and database moved to a separate environment (staging), blocked from search engines
2. Change and check it there — theme swap, menus, widgets, form behaviour
3. Reconcile the URL list — decide the 301 redirects for any page that disappears, before you launch. Skipping this is why search traffic drops right after a redesign
4. Cut over, then verify the old addresses

Our work process page walks through the whole procedure step by step.

The install screen alone usually tells you enough.

• Last updated — if nothing in six months, hold off
• Active installations — more users means problems surface and get fixed faster
• Compatibility with your WordPress version
• Unanswered threads in the support forum — does anyone reply?

And one more: does this really need to be a plugin? More often than you would expect, the core or the theme already does the job.

There is no correct number. One heavy plugin can cost more than thirty light ones.

What matters is what each plugin loads on every page. A form plugin used only on the contact page but adding its script and stylesheet site-wide is a bigger problem than the count.

If you want one rule, use this: can you explain what this plugin currently does? A plugin you cannot explain has no reason to be active.

Do not switch them off one at a time — halve them. With twenty plugins, disable ten and check: if the symptom goes, the culprit is in the disabled half; if it stays, it is in the other. Twenty plugins narrow down in about five rounds.

If disabling all of them changes nothing, it is the theme — switch to a default theme briefly to confirm.

⚠ Do not do this on the live site. While a plugin is off, visitors see the page without that feature. Reproduce on a copy and narrow it down there; if that is impossible, at least pick your quietest hours.

Before which, decide how many — running two “all-in-one security” plugins stacks two firewall layers that block each other’s requests, and makes tracing any problem nearly impossible. Use one.

And some things no plugin can do for you. Overdue updates, a weak administrator password and server configuration all sit outside the plugin, so adding one on top of them increases your confidence without reducing your exposure.

The order is updates, then accounts, then server configuration — and only then a plugin.

First check whether the server already caches. If nginx or your host holds a page cache and you add a plugin cache on top, the two layers invalidate at different moments and you get “the admin sees the new page, visitors see the old one” — among the most tiresome bugs to trace.

On shared hosting with no server cache, a caching plugin genuinely helps. Use one, and make sure checkout, login and form-submission paths are excluded.

We handle this at the server layer instead. Keeping the cache in nginx and Redis rather than in the application is how each layer keeps exactly one responsibility.

A reasonable fear. But postponing is the riskier option — you stay exposed to published vulnerabilities for however long you wait, and the longer you leave it the more likely a bulk update is to break something.

What makes it not frightening is having an order.

1. Back up first — files and database. With somewhere to return to, an update becomes a reversible action
2. One at a time — update several at once and you cannot tell which one broke it
3. Check afterwards — just the critical paths: home page, contact form, checkout

For an important site, updating on a copy first is the surest way.

No. Delete it.

A deactivated plugin’s files still sit on the server, and vulnerable code inside them can sometimes be called directly. Not being active is not the same as not being reachable. Deactivated plugins also slip past update notices and quietly go stale.

Deleting may remove data the plugin created, so back up first. If you might return to it, export its settings before you go.

Before paying, try inverting the design. Situations that seem to need a paid feature are often the result of dividing the data the wrong way.

A common example is “I need to repeat this item several times”. Instead of buying a repeater field, promote the item itself into its own content type — sorting, searching and the API all fall out of core behaviour, and the admin screen gets simpler rather than more complex.

We built this site that way. Not to work around a paid licence, but because designing around the constraint produced the better result.

PHP stopped mid-execution and the error is not being printed. It is almost always whatever you changed last — the plugin you just activated, the update you just ran, the code you just pasted.

1. Make the error visible — turn on WP_DEBUG and WP_DEBUG_LOG in wp-config.php and the cause is written to wp-content/debug.log, down to the file and line
2. Disable the culprit — if you cannot reach the admin, rename the plugin’s folder under wp-content/plugins/ over FTP or SSH and it deactivates
3. Suspect the theme too — if it is not a plugin, rename the theme folder to fall back to a default theme

⚠ Turn WP_DEBUG back off afterwards. Left on, error messages expose your server paths.

Try the password reset email first. If it never arrives, your site may not be able to send mail at all — that is a different problem.

If email is not an option, change it on the server. In a database tool such as phpMyAdmin, set the user’s user_pass in wp_users to a new value using the MD5 function; WordPress re-hashes it properly on the next login. If WP-CLI is available, a single wp user update is safer.

If the password is right but you keep bouncing back to the login screen, check your address settings — a mismatch in www or http/https produces exactly this.

Both parts, or it will not restore.

• Files — especially wp-content/ (themes, plugins, uploaded images) and wp-config.php
• Database — posts, pages, settings and users all live here

Files without the database restore an empty site; the database without the uploads restores posts full of broken images.

Keep copies off that server — if the machine itself fails, a backup stored on it fails with it. Match the frequency to how often your content changes, and always take one immediately before major work.

There is no way but to restore one. Whether your backup comes back to life must be established before an incident, not during it.

The method is simple: unpack it onto a temporary or local environment, bring the site up, and check the home page, login, images and contact form. Two problems surface here regularly — the database is there but the uploads are missing, and the addresses are still baked to the old domain so every link points away.

One rehearsal turns a backup from something you have into something you can use.

Back up, then plugins and themes, then core.

Plugins go first because versions compatible with the new core are usually already published. Update core first and an outdated plugin breaks on it, which makes it easy to blame the core update instead.

Treat the PHP version separately. Raising it on the same day as a WordPress update leaves you unable to tell which one broke things — spacing them a few days apart is faster in the end.

It depends.

Leave security (minor) updates on. Their scope is narrow so the risk of breakage is low, and every day of delay is another day of exposure.

Be careful with major updates and plugin auto-updates. If one lands at 3am and breaks the site, you find out in the morning.

The deciding question is how fast you would find out. With monitoring in place, automatic is fine; without it, updating by hand and checking immediately is better. It is the same reason we block unverified updates from rolling in on our own stack — they conflict with deploying what you tested.

Four steps: copy the files, copy the database, update the database credentials in wp-config.php, then point DNS at the new server.

Where people get caught is that addresses are embedded in the content. When the domain changes, every old URL in posts and settings must change too — and a plain find-and-replace in SQL will not do. WordPress stores some settings as serialised strings that carry their own length values; replacing text with a different length corrupts those settings entirely.

Use a tool that understands serialisation (WP-CLI’s search-replace does).

And verify the site on the new server before switching DNS — check afterwards and visitors see the broken state in the meantime.

If the site produces revenue or enquiries, yes. Staging is what makes “do not experiment on production” possible.

It does not need to be elaborate — a copy in a subdirectory of the same server covers most of the purpose. Just hold to two rules.

• Block search engines — once indexed you have two identical sites competing against each other
• Stop payments and outgoing mail from actually firing — test orders emailing real customers is a common accident

Order matters. Do not start by deleting.

1. Preserve the current state — copy the compromised files and database as they are. How they got in can only be learned from that copy; delete first and you never will
2. Change every password — admin accounts, database, FTP/SSH, hosting account. Leave one and they come back
3. Restore from a backup taken before the compromise — anything after it may already be tainted
4. Close the way in — usually an outdated plugin or theme. Skip this and the same thing happens again right after you recover

⚠ A recovery without step 4 is not a recovery — it just buys time until it repeats.

First ask whether you actually use comments. If not, turning the feature off entirely is the surest fix — less moderation, and less personal data (commenter IPs and emails) to hold.

⚠ But unchecking “allow comments” in settings is not enough. That only hides the form; spam bots never look at the form and post straight to the comment endpoint. It stops only when that endpoint is closed too.

If you do need comments, one spam-filter plugin plus “first comment must be approved” is a reasonable combination.

“Suddenly” narrows things considerably. Start with whatever changed recently.

• A newly activated plugin or a recent update — if the timing matches, that is almost certainly it
• More traffic — real visitors, or a bot hammering you. The access log tells them apart
• Server resources — a full disk or exhausted memory slows everything
• A bloated database — accumulated revisions, transients and log tables make queries crawl

If you cannot tell where it is slow, compare the same page logged in and logged out. Fast only when logged out means a cache is working; slow both ways points at the server or the database.

Whoever you ask, having these three ready makes it go faster.

• The symptom and its timing — since when, and after what
• Your hosting — what kind, and whether you have root access
• Whether you have a backup — if not, take one now

If you need the upgrade, performance and security dealt with in one pass, that is the scope of our optimization program. The work process is published step by step, and what is not included is written with equal weight.

If you would rather do it yourself, start by finding out what is outstanding with our free audit plugin.

Judge by numbers taken under identical conditions, not by feel. Lighthouse in your browser’s developer tools, or PageSpeed Insights, is a fine start.

There are rules to measuring.

• Three runs on the same URL, same device profile, same time of day, and take the median. A single run wanders
• Warm the cache first — the first request is a cache miss and not what real users experience
• Do not measure while logged in; the admin bar and cache bypass make it unlike a visitor’s experience

These are the same rules we follow when producing a before/after report.

For most sites the order is:

1. Images — originals uploaded far larger than they display is the most common problem and the biggest win
2. Page caching — stop rebuilding the same page in PHP on every request
3. Remove unused plugins — starting with those loading scripts and styles site-wide
4. PHP version and OPcache — on an old PHP, simply upgrading makes a difference
5. Database cleanup — accumulated revisions and transients slow queries down

⚠ People often start at the fine-tuning end instead. It is common for a single oversized image to outweigh everything else combined. Measure, then fix.

A page cache stores the finished screen. An object cache stores the database results used to build it.

They cover different ground. Page caching helps logged-out visitors enormously, but cannot be used where each person sees something different — logged-in users, the admin, a shopping cart. That is where an object cache takes over, keeping repeated queries from reaching the database at all.

So the difference is most noticeable on sites with many logged-in users: memberships, shops. For a static brochure site, page caching alone may well be enough.

Start by knowing your versions exactly — WordPress core, the theme, and every plugin. Known vulnerabilities are published per software and version range, so without the version there is nothing to judge against.

Then check them against a vulnerability database. Free tooling automates this — our own site audit plugin queries core, plugins and themes in one pass.

⚠ One caution: “no known vulnerabilities” is not “secure”. It only means nothing is on the published list — weak passwords and wrong file permissions never appear as a CVE.

Yes, and it is usually more decisive than a plugin.

• Disable the file editor — with DISALLOW_FILE_EDIT, a stolen admin account can no longer plant code through the theme editor
• Block PHP execution in the uploads folder — the last gate stopping an upload flaw from becoming remote code execution
• Close XML-RPC if you do not use it; it is an amplification path for brute-force attempts
• Stop username enumeration — an open author list hands attackers the login name to start from
• File permissions — code read-only to the web server, writable only in uploads

Most of this is out of reach on shared hosting — which is why the type of hosting decides how much security work is possible.

Start with the technical groundwork. Good content cannot rank if it is never read.

• Is indexing blocked? “Discourage search engines” under Settings → Reading stops everything — frequently switched on during development and forgotten
• Is a sitemap submitted? To Google Search Console, and to Naver if your audience is Korean
• Are URLs readable? Post names beat ?p=123
• Are titles and descriptions unique per page? Repeated text leaves search engines unable to decide which page to rank
• Is it fine on mobile, and fast enough?

Once this is in place, content starts paying off.

Check in order.

1. Settings → Reading — is “discourage search engines” off?
2. robots.txt — open yoursite/robots.txt and confirm it is not blocking crawlers
3. Is there a noindex in the page source? An SEO plugin setting or the theme may be adding one
4. Have you registered in Search Console and requested indexing? A new site takes time to be discovered on its own

If it is registered and indexed but simply ranking poorly, that is a different problem — then it is about content and internal linking.

The process differs from Google. Register the site with Naver Search Advisor, verify ownership, then submit your sitemap and RSS feed.

What you prepare on the WordPress side is much the same as for Google — a working sitemap, a title and description on every page, and indexing not blocked. The ownership-verification meta tag goes into your SEO plugin’s verification field.

Do bear in mind that Korean search results lean heavily on Naver’s own blog and community content, so a standalone website can take longer to gain ground there than it would on Google.

Before hiring anyone, agree on what will be measured and how. Without that, all you have afterwards is the word “better”.

At minimum, settle these three.

• Which URLs are the reference
• Which tool and conditions — same tool, same device profile, median of three runs
• The raw before/after artefacts — the report files themselves, not just a score

Our support program reports exactly this way, and anything that did not improve is written down as it is, with the reason. Reporting selectively means that the moment one omission is noticed, every other number loses its credibility too.

No. Everything is verified in a cloned environment before it touches the live server, and we agree the cutover for your quietest hours. If a step genuinely needs downtime — swapping the PHP version, for example — we tell you beforehand, and it is normally a matter of minutes.

Server hosting with root or sudo access — a VPS, a cloud instance (AWS, GCP, Vultr and so on) or a dedicated server. We do not take on shared web hosting such as cPanel: without permission to configure Docker, Redis and nginx we cannot deliver what we promised.

Your report uses the median of three runs on the same URL under the same conditions, before and after. Response time, database query count and auditing scores are compared as numbers — and anything that did not improve is written down as it is, with the reason.

A full backup of files and database is made before anything begins. We only work from a position where the previous state can be restored immediately if something goes wrong.

By Korean bank transfer at ₩270,000 including VAT, or by PayPal at $200 USD. For a transfer we send the next instructions once it clears; with PayPal they follow immediately. Work begins after payment is confirmed.

For two weeks after delivery we fix defects in the same scope at no charge. You also keep the Docker configuration files, so the identical environment can be reproduced at any time — which makes the next round of maintenance cheaper too.

Included — upgrading WordPress, the theme and plugins to current versions; performance work (Redis object cache, nginx FastCGI cache, OPcache); technical SEO; fixing security vulnerabilities (PHP permissions, nginx hardening); PHP source refactoring; and a reproducible Docker-based deployment.

Not included — copywriting and design refreshes, server rental costs, paid theme or plugin licences, and work on shared web hosting.

The scope is written down before you pay so that there is nothing to dispute later. If anything is unclear, we settle it at the request stage.

No. Clear the checkbox on the request form and we will not install it.

It is included by default because it goes up alongside the Docker stack we are deploying anyway — adding a separate sign-up step would only create work for you.

The trial ends by itself after a month and does not roll into a subscription. If you want to keep it, you buy a pass separately at that point.