The voice agent explains any task, answers questions grounded in this plan, and records a brain dump. Voice feedback is read-only and cannot approve or execute work. Allow the microphone when your browser asks.
The explicit Sonnet rollback keeps the existing capsule-only protocol. A lost connection retries the same Sonnet engine twice and reloads the complete persisted conversation. It never changes models during a conversation.
Sonnet 5 · no fallbackVoice answers are review evidence. Approval, sending, spending, and production changes stay in the originating chat. Voice trouble in this page? Open the standalone voice page.
Plan: /Users/agency/Documents/Agty/csupi/action-plans/2026-08-18-csupi-seo-ppc-phone-clicks-30-day-plan.md
J or K, to open it.1 delegate, 2 drop, 3 idea, 4 ask first, 0 clear, J and K move between tasks.!, which makes them binding.Make one verified `tel_szam_katt` event fire for every genuine `tel:` click, with page, placement, device, and traffic-source context, across all live indexable pages.
The chosen success metric cannot guide SEO or PPC while the post-outage phone-click event is not proven end to end.
Later optimizations could reward accidental clicks, double-counted clicks, or only a subset of phone buttons.
Creates one consistent proxy that can compare landing pages, campaigns, search terms, and CTA placements.
Tag Assistant and GA4 DebugView show one event per tested phone-icon click on the homepage and representative service and location pages. The event includes stable page and placement fields. A Data API readback confirms the event after normal processing. A weekly source-and-page scorecard keeps calls, jobs, and revenue explicitly UNKNOWN unless manually supplied. 80/20: Instrument the homepage plus the top four paid landing pages first, then roll the same verified pattern to the remaining live pages.
flowchart LR A[Current evidence] --> B[Implement one event contract with useful fields] --> C[Creates one consistent proxy that can compare landing pages, campaigns, search terms, and CTA placements.]
flowchart TD
S1[Inventory every tel link and current trigger] --> S2[Implement one event contract with useful fields]
S2[Implement one event contract with useful fields] --> S3[Test representative pages and verify GA4 readback]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Import the validated GA4 key event into Google Ads, observe it first, then make it the selected biddable action only after volume and deduplication checks pass.
The active campaign currently has no comparable conversion signal, so PPC cannot optimize toward the user's chosen proxy.
Bidding can continue to maximize traffic quality indirectly, or it can learn from a noisy event if the proxy is promoted too early.
Lets PPC optimize toward visitors who actively tap the phone control while preserving an explicit proxy label.
The imported action is visible, receives verified paid events, has the intended count method and attribution, and is initially observation-only. Promotion to Primary occurs only after a documented seven-day quality check. No simultaneous goal or budget change is made. 80/20: Create and observe the imported action first. Promote it only when paid phone clicks reconcile with GA4 and duplicate-event tests.
flowchart LR A[Current evidence] --> B[Import the event and keep it observation only] --> C[Lets PPC optimize toward visitors who actively tap the phone control while preserving an explicit proxy label.]
flowchart TD
S1[Verify Ads and GA4 linking plus key event status] --> S2[Import the event and keep it observation only]
S2[Import the event and keep it observation only] --> S3[Reconcile seven days then select the campaign goal]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Classify the last 60 days of search terms by serviceability and intent, then exclude only confirmed irrelevant terms using the narrowest safe negative match type.
The current report shows paid clicks from distant cities and competitor-name queries, including one remote-city term with 26 clicks, but the service boundary is not encoded in the account.
Budget can continue buying visits that cannot become useful phone-icon clicks or completed jobs.
Concentrates spend on searches Csupi can actually serve without reducing valid national or international demand by mistake.
A search-term ledger marks every material-cost term as keep, negative, or needs service-area confirmation. Only approved negatives are added. A before-and-after report tracks irrelevant click share and phone-click rate without claiming call volume. 80/20: Review the 20 highest-cost terms first and block only unambiguous waste after confirming the real service area.
flowchart LR A[Current evidence] --> B[Confirm serviceable locations and intent rules] --> C[Concentrates spend on searches Csupi can actually serve without reducing valid national or international demand by mistake.]
flowchart TD
S1[Export and rank material search terms] --> S2[Confirm serviceable locations and intent rules]
S2[Confirm serviceable locations and intent rules] --> S3[Apply reviewed negatives and compare the next seven days]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Re-audit every active ad group, replace any remaining literal keyword-insertion text and excessive pinning, then pair each high-intent group with truthful ad copy and the closest matching landing page.
The project history verified a systemic broken keyword-insertion pattern and highly constrained RSA combinations. Only the generic ad was confirmed repaired at that time.
Broken or generic ads can lower trust and relevance, while a mismatched final URL makes users search again before tapping the phone icon.
Produces clearer ads and a shorter path from query to the relevant phone CTA.
A fresh Ads readback shows no literal keyword-insertion artifacts in enabled ads. Each active high-intent ad group has truthful, diverse RSA assets, controlled pinning, and a final URL that directly matches the query and promise. The 15-minute claim is used only if verified true. 80/20: Fix the enabled ad groups with spend first, starting with the generic and highest-cost location groups.
flowchart LR A[Current evidence] --> B[Draft truthful query-specific RSA assets] --> C[Produces clearer ads and a shorter path from query to the relevant phone CTA.]
flowchart TD
S1[Read back enabled ads and final URLs] --> S2[Draft truthful query-specific RSA assets]
S2[Draft truthful query-specific RSA assets] --> S3[Replace only verified defects and validate live readback]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Test one material hero CTA change, such as clearer availability, service area, or price-explanation context, while keeping the phone number and underlying service promise unchanged.
The site already has many phone links, but there is no reliable evidence showing which wording and placement produce intentional phone-icon clicks.
Adding more buttons or redesigning many pages at once would create noise and make the effect impossible to attribute.
Finds a repeatable CTA pattern using the chosen proxy without risking a site-wide conversion change.
One page and one variable are selected from verified paid traffic. Baseline and variant windows use the same event contract. The result reports sessions, phone clicks, rate, device mix, and uncertainty. Rollout occurs only if the direction is credible and no guardrail worsens materially. 80/20: Test the homepage hero only after at least seven clean measurement days.
flowchart LR A[Current evidence] --> B[Record a clean baseline then launch the reversible variant] --> C[Finds a repeatable CTA pattern using the chosen proxy without risking a site-wide conversion change.]
flowchart TD
S1[Choose the highest-traffic eligible page and one variable] --> S2[Record a clean baseline then launch the reversible variant]
S2[Record a clean baseline then launch the reversible variant] --> S3[Compare phone-click rate and decide keep or revert]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Build a complete old-to-new URL inventory from Search Console history, server behavior, and internal links, then correct every mismatched, chained, missing, or homepage-fallback redirect.
Search Console pages with data contracted from 205 to 63 after the URL transition, while the current live sample itself is technically indexable.
Historical signals and users can keep landing on irrelevant destinations, redirect chains, or soft-404-like homepage fallbacks.
Gives Google and users one consistent canonical destination for every historically valuable URL.
The mapping covers every old URL with material clicks or impressions. Each retiring URL returns one permanent hop to the closest equivalent page or an honest not-found response. Targets return 200, self-canonicalize, appear in the sitemap when indexable, and receive direct internal links. 80/20: Fix the 20 old URLs with the most historical impressions first.
flowchart LR A[Current evidence] --> B[Approve the closest equivalent destination for each] --> C[Gives Google and users one consistent canonical destination for every historically valuable URL.]
flowchart TD
S1[Export historic URLs and crawl their current responses] --> S2[Approve the closest equivalent destination for each]
S2[Approve the closest equivalent destination for each] --> S3[Implement redirects and verify HTTP canonical sitemap and links]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Create a ten-URL recovery queue, inspect indexed and live states, resolve blocking reasons, then request indexing only for corrected canonical pages and monitor them weekly.
The live site can be crawlable while Google still holds an older canonical, has not discovered the page, or has chosen not to index it.
Submitting uncorrected or low-priority URLs wastes limited inspection capacity and creates activity without resolving the cause.
Front-loads the pages most likely to restore visibility and gives a per-URL explanation for success or failure.
The queue records indexed status, last crawl, user canonical, Google canonical, live-test outcome, source discovery, and request date for exactly ten priority pages. Requests are sent only after technical checks pass. Weekly follow-up separates indexed, pending, and rejected outcomes. 80/20: Inspect the homepage, pricing target, autoszállítás, motorway hub, furgonmentés, gépszállítás, and four historically strongest recovered URLs.
flowchart LR A[Current evidence] --> B[Inspect indexed and live states then fix blockers] --> C[Front-loads the pages most likely to restore visibility and gives a per-URL explanation for success or failure.]
flowchart TD
S1[Rank ten URLs by historical value and current opportunity] --> S2[Inspect indexed and live states then fix blockers]
S2[Inspect indexed and live states then fix blockers] --> S3[Request indexing and track the weekly state]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Use Search Console query-page evidence and the ten-keyword SERP comparison to produce one concise homepage brief for `autómentés`, `autómentő`, `autómentés budapest`, and `autómentő budapest`.
These are the largest measured demand themes, while competitors outrank Csupi materially for all four. The homepage already contains the core terms, so blind repetition would add little.
Generic rewriting can damage the currently clear title and initial HTML without addressing search intent or click appeal.
Clarifies the offer, geography, availability, and phone action on the page that should own the broadest demand.
The brief documents the current and proposed title, snippet copy, primary heading relationship, supporting sections, and internal anchors. Every added claim is verified. After publication, Search Console tracks the four queries and homepage CTR without assuming Google will use the supplied title or description. 80/20: Change only the title or supporting copy that a query-page review proves is weak or inconsistent.
flowchart LR A[Current evidence] --> B[Draft one factual core-intent homepage brief] --> C[Clarifies the offer, geography, availability, and phone action on the page that should own the broadest demand.]
flowchart TD
S1[Compare query page and current SERP title evidence] --> S2[Draft one factual core-intent homepage brief]
S2[Draft one factual core-intent homepage brief] --> S3[Implement minimal changes and monitor four queries]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Create one useful pricing-intent page explaining the factors that determine the quote, what information the caller should prepare, representative examples only when verified, and a clear phone CTA for an exact quote.
Csupi ranks 19 for `autómentés árak`, while the strongest supplied competitor ranks 2 and uses an exact price-intent title and H1.
Price-sensitive searchers may choose competitors before contacting Csupi if they cannot understand how a quote is formed.
Answers the price question honestly and moves high-intent visitors toward an informed phone-icon click.
The page has a distinct purpose, verified pricing logic, descriptive title and H1, examples or ranges only when approved, FAQ content based on real customer questions, one canonical URL, sitemap inclusion, and internal links from the homepage and relevant service pages. 80/20: Publish the pricing-factor explanation and quote checklist even if exact price ranges cannot be verified yet.
flowchart LR A[Current evidence] --> B[Write the people-first page and phone CTA] --> C[Answers the price question honestly and moves high-intent visitors toward an informed phone-icon click.]
flowchart TD
S1[Verify real pricing factors and frequent caller questions] --> S2[Write the people-first page and phone CTA]
S2[Write the people-first page and phone CTA] --> S3[Publish link inspect and measure price-query traffic]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Turn the existing autoszállítás page into the clear owner for `autószállítás`, with service scenarios, eligibility limits, quote inputs, genuine job proof, and a context-specific phone CTA.
Csupi ranks 36 for `autószállítás`, while the strongest supplied competitor ranks 1 and exposes a dedicated autoszállítás page.
A generic or thin page can fail both search intent and the visitor's practical questions before a phone click.
Connects a high-intent transport query to a page that explains exactly when and how Csupi can help.
The page includes verified vehicle and route scenarios, required quote information, constraints, first-hand proof, descriptive title and H1, one primary phone CTA, and links from relevant vehicle-transport and location pages. Search Console tracks the target query-page pair. 80/20: Improve the existing page rather than creating another competing autoszállítás URL.
flowchart LR A[Current evidence] --> B[Add verified scenarios proof and quote inputs] --> C[Connects a high-intent transport query to a page that explains exactly when and how Csupi can help.]
flowchart TD
S1[Audit the existing page against autoszállítás intent] --> S2[Add verified scenarios proof and quote inputs]
S2[Add verified scenarios proof and quote inputs] --> S3[Strengthen internal links and track the query page pair]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Create one useful `autópálya autómentés` hub that routes visitors to the correct M0, M1, M5, M6, M7, and M31 pages, explains emergency steps, and links to phone help without duplicating the route pages.
Csupi is outside the top 50 for `autópálya autómentés`, while a supplied competitor ranks 3. The site has multiple motorway pages but lacks one clear broad-intent owner.
Signals and users can remain fragmented across route pages, while the broad query has no obvious destination.
Creates a logical entry point that helps search engines and stranded drivers reach the right route-specific page and phone CTA.
The hub provides unique broad-intent guidance, descriptive links to every relevant motorway page, verified service coverage, and a clear phone CTA. Homepage and service navigation link to the hub. Furgonmentés and gépszállítás pages retain their current primary topics and are monitored as guardrails. 80/20: Publish the hub and the ten most valuable descriptive internal links first.
flowchart LR A[Current evidence] --> B[Write the unique hub and route decision path] --> C[Creates a logical entry point that helps search engines and stranded drivers reach the right route-specific page and phone CTA.]
flowchart TD
S1[Map the broad motorway intent and existing route pages] --> S2[Write the unique hub and route decision path]
S2[Write the unique hub and route decision path] --> S3[Add descriptive links then monitor hub and guardrail pages]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2Create a weekly process that turns completed work into factual job proof, sends a neutral review link or QR code to genuine customers, and drafts short personalized replies without incentives, gating, or requested wording.
The live review display already works and shows strong trust, but the next sustainable gain requires fresh genuine experiences and useful first-hand evidence rather than more review markup.
Without an operating process, trust content becomes stale and review activity depends on memory. Aggressive solicitation would create policy and reputation risk.
Provides prospective customers with current proof and gives real customers a neutral path to share their experience.
The workflow includes a consent-safe request template, official review link or QR code, no incentive, no rating filter, a reply guide, and a real-job content template with date, situation, area, vehicle, method, photo rights, and factual outcome. Website proof contains no self-serving review rich-result claim. 80/20: Prepare the templates and publish three verified job-proof entries. Do not send or reply until GBP access and the customer-contact process are confirmed.
flowchart LR A[Current evidence] --> B[Create neutral request reply and job-proof templates] --> C[Provides prospective customers with current proof and gives real customers a neutral path to share their experience.]
flowchart TD
S1[Verify customer contact and photo consent rules] --> S2[Create neutral request reply and job-proof templates]
S2[Create neutral request reply and job-proof templates] --> S3[Publish three proof entries and monitor phone clicks]
S3 --> D{Evidence meets done}
D -- yes --> DONE[Verified]
D -- no --> S2